feat(dev): une seule commande pour demarrer, et la porte d'entree enfin trouvable - #56

…este

Trois ajouts à deploy/, chacun comblant un trou que le nouveau couple de
scripts aurait sinon hérité en silence :

- TestTheShellScriptsAreValidAccordingToTheShell (shell_test.go) analyse
  désormais dev.sh par « sh -n », à côté de .devcontainer/post-create.sh.

- TestEveryPowerShellScriptParses (powershell_test.go) s'appuie sur
  powerShellScripts(t), qui parcourt tout le dépôt, au lieu de son propre
  glob limité à deploy/windows/*.ps1. Ça fait entrer make.ps1 ET dev.ps1
  dans le seul banc qui invoque réellement le parseur PowerShell — make.ps1
  n'était vérifié par aucun interprète jusqu'ici, et dev.ps1 aurait hérité
  du même trou.

- TestDevScriptsCheckTheSameThings (parity_test.go) tient la parité entre
  les deux scripts : les trois mêmes contrôles (Docker, la CLI devcontainer,
  le lancement) doivent apparaître dans les deux fichiers. L'unique écart
  légitime — le contrôle du groupe docker, qui n'existe pas sous Windows —
  est vérifié par la même mécanique que les exceptions de parité des
  installeurs : la raison doit être écrite, et retrouvée dans le fichier qui
  n'a pas le contrôle, pas seulement affirmée dans le banc.

Les trois ont été vus rougir sur une casse volontaire (syntaxe cassée sur
chaque script, contrôle retiré d'un des deux) avant d'être restaurés.

Trois corrections mesurées sur dev.sh et dev.ps1, après relecture :

- La recette Fedora de dev.sh employait la syntaxe DNF4 (« --add-repo »).
  Fedora est passée à DNF5 en version 41, et toutes les versions encore
  maintenues répondent « argument inconnu » à cette syntaxe — l'utilisateur
  tape la ligne qu'on lui donne et n'obtient rien. Remplacée par la syntaxe
  DNF5 (« addrepo --from-repofile »), telle que documentée aujourd'hui.

- docker-buildx (Arch) et docker-buildx-plugin (Fedora, déjà corrigé) ajoutés
  aux deux recettes : sans eux, le contrôle 1 (« docker info ») passe et le
  contrôle 3 (« devcontainer up », qui construit l'image) tombe sur
  « BuildKit is enabled but the buildx component is missing or broken ».

- Sous Windows PowerShell 5.1 — pas sous pwsh 7, vérifié sous les deux —
  $ErrorActionPreference = 'Stop' rend TERMINANTE toute écriture sur le flux
  d'erreur d'une commande native dont la sortie est redirigée, même quand
  cette commande réussit et n'écrit qu'un avertissement. Reproduit pour de
  vrai : un « cmd /c "echo err 1>&2 && exit 0" » réussi devient une exception
  attrapée par le catch sous 5.1. « docker info » sur un moteur WSL2 émet un
  avertissement sur stderr, et « devcontainer --version » hérite de ceux de
  Node — les deux auraient été déclarés en panne sous 5.1 alors qu'ils
  répondent. Une fonction Test-CommandRuns desserre la préférence le temps de
  l'appel seulement, et la restaure aussitôt ; les deux sondes s'appuient
  désormais dessus plutôt que sur deux blocs try/catch dupliqués.

Deux corrections mineures à côté : les en-têtes des deux scripts recopiaient
des nombres (« quatre commandes », « six des sept contrôles ») que rien ne
tenait à jour et que le handbook contredisait déjà ; ils disent maintenant le
critère et renvoient au handbook. « Deux causes possibles » devient « Causes
possibles », le message n'en imprimant qu'une sur macOS.

TestDevScriptsCheckTheSameThings cherchait « devcontainer » pour juger le
contrôle 2, et ce mot est un sous-mot de « devcontainer up », le marqueur du
contrôle 3 : il était donc vrai par construction dès que le troisième
l'était, et ne pouvait pas voir le contrôle 2 disparaître — précisément celui
que la CLI --version vient de réparer. Remplacé par « devcontainer --version »,
le texte que les deux scripts exécutent réellement pour ce contrôle. Une
deuxième boucle vérifie maintenant l'ordre des trois marqueurs dans chaque
script, ce que le commentaire de la fonction affirmait sans le vérifier. Le
message d'échec de la boucle de présence ne suppose plus que l'autre script
porte le marqueur : il le constate, avec un message distinct selon qu'un seul
côté a perdu le contrôle ou que les deux l'ont perdu ensemble.

TestNoShellScriptExitsOnATestThatIsSimplyFalse (shell_test.go) n'analysait que
linux/*.sh, alors que dev.sh pose le même set -e et est exactement le genre de
script dont une panne de premier lancement doit parler plutôt que sortir en
silence sur un test simplement faux. Il rejoint la liste, comme son voisin
sh -n l'a fait pour dev.sh dans un lot précédent.

Le chemin conteneur du guide de demarrage manquait le git clone, ne disait
rien de l'installation de Docker et laissait le contributeur Linux decouvrir
seul le blocage du groupe docker au premier lancement. Les scripts dev.sh
et dev.ps1 verifient et guident deja pour ca, plateforme par plateforme : la
page renvoie desormais vers ces deux commandes plutot que de dupliquer leurs
instructions, et garde le detail des commandes devcontainer pour qui prefere
le savoir plutot que le croire.

Adoucit aussi la revendication non verifiee sur les IDE JetBrains : seuls
VS Code et ses forks implementent la specification devcontainer avec
certitude.